Cloud Transition for QoS Modeling of Inter-Organizational Workflows

In this paper we present an architecture for enabling complex workflow execution in Cloud-like environments. We focus mainly on modeling concepts and techniques to enhance accessibility to Cloud services by different kind of users. Complex workflow tasks need in some cases to be mapped to distributed resources and involves the cooperation between several partners. Workflow management is critical to a successful long-term Cloud computing strategy. The notion of inter-organizational workflow still needs conceptual and technical support especially in complex and dynamic environments like Clouds. New ways to tackle this problem have to be found. Therefore, existing workflow architectures need to be adapted for the Cloud and workflow management systems (WfMS) should be integrated with Cloud infrastructure and resources [3]. In this paper we use Inter-Cloud Workflow Petri Nets (ICWPN), an approach for enabling workflows in an (Inter)-Cloud environment. A specialized Cloud Task Transition (CTT) is introduced to facilitate the connection to the Cloud and to support Quality of Service (QoS) management [1]. The CTT (see Fig. 1 (a)) is based on the Workflow Task Transition [2], which is the core of the workflow net formalism in Renew1 (Reference Net Workshop). Workflow modelers specify their requirements as parameters to the CTT in form of tuples (S, Q, I), which correspond respectively to the Cloud service (S) that they want to use (it can be a storage or a compute service), the QoS constraints (Q) consisting of deadlines or costs and input data (I) consisting either of required files in case of a storage or scripts if they want to execute their codes on the Cloud. Synchronous channels are used to make the connection with the WfMS, which controls the completion of the task. It either initiates the firing or cancels it and all input parameters are put back onto the input places. To see how the CTT is used in practice, we introduce a Cloud-based workflow architecture, it is depicted in Fig. 1 (b). It includes three basic layers from top to bottom: user applications layer (UL), middle-ware layer (ML) and the resource layer (RL), which consits mainly of Cloud services. In our approach we view the process of executing an application in an Inter-Cloud environment as a 6-phase process: (1) Users use the offered modeling tools consisting mostly of Renew and the introduced CTT to specify the requirements (Cloud services, QoS constraints, specific input data) for their applications using Petri nets models. (2) 1 Renew is available at http://www.renew.de (a) The Cloud Transition (b) General Cloud Workflow Architecture Fig. 1. Cloud-based Workflow Management A list of requirements is created consisting of required services as well as their related QoS constraints. (3) Make a request to the Cloud Service Repository (CSR) which is accessible by the WfMS to achieve workflow tasks (4) Based on the above steps (2-3) a decision is made by the Decision Maker who determines whether the workflow tasks will be executed locally or using Cloud resources. (5) After that the workflow tasks are mapped to the adequate resources. (6) When the workflow is deployed, information about Cloud providers and the state of their services are constantly updated. Here we focused primarily on Cloud technologies. Nevertheless, the introduced model (see Fig. 1(b)) can be also applicable to other dynamic domains where distributed resources are shared and dynamically allocated and usually priced.